These ansible(1) playbooks still build Docker images, so I guess under the hood they still do the same thing that a Dockerfile and docker(1) could do. Can't we achieve the same with just docker(1) and a Dockerfile?

That is, can you explain how is ansible(1) necessary (or better than docker(1)) to achieve this?

Yes, they do the same, and if I could I would have stick with the docker and dockerfile architecture, but it isn't possible. At least if we want to obtain the logs without having to do some nasty things, like 1 and 2 (which in reality doesn't work because when something fails the container build never arrives to this point).

In addition, when dockerfile build fails the container is destroyed, which prevents us from accessing it to see what has happened. Which brings us to the previous point, getting the logs.

Using Ansible allows us to maintain a similar approach to what we had until now: build this project for different distributions, run the workflow locally, maintain some independence from Github actions, etc. On top of that, we'll be able to obtain all the logs, and if we are running the workflow locally and anything fails we'll be able to access the containers to debug what's happening.

Yes, they do the same, and if I could I would have stick with the docker and dockerfile architecture, but it isn't possible. At least if we want to obtain the logs without having to do some nasty things, like 1 and 2 (which in reality doesn't work because when something fails the container build never arrives to this point).

This does actually work (I could see the logs). I've seen it fail once (not exactly this; it was the same trick, but in a github actions), and documented it here:
#956 (comment)

And I wrote some small Dockerfile to test this with a docker build:

$ cat Dockerfile 
FROM debian

RUN bash -c "trap 'cat </etc/os-release >&2' ERR; false;"

$ sudo docker build .
Sending build context to Docker daemon  23.55kB
Step 1/2 : FROM debian
 ---> 2a033a8c6371
Step 2/2 : RUN bash -c "trap 'cat </etc/os-release >&2' ERR; false;"
 ---> Running in 3c6f20ae7c6b
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
The command '/bin/sh -c bash -c "trap 'cat </etc/os-release >&2' ERR; false;"' returned a non-zero code: 1

Or do you have any case where it failed and it didn't work?

Edit: Now I realize you probably meant the COPY trick is the one that doesn't work). That's probably true. But stderr should be good-enough.

I want to avoid the complexity of using ansible(1) if possible, and if trap(1) works, I prefer it.

As an alternative, we could consider that make check could directly print to stderr, instead of a log. Let the user redirect the logs if it wants to. This is very much preferred behavior, IMO. Then we wouldn't need to do trap(1) magic to print the logs on failure.

The trap works, but it feels nasty and it forces users to use the Github scroll, which doesn't work very well.

Regarding COPY, that doesn't work and we do not only want to see the build logs but also the configuration files. This would feel like an improvement to me considering our current situation.

Finally, this would also give us the opportunity of capturing all the test logs when #835 is implemented and running.

I think this is ready for review, so I'm moving it out of draft state.